Call FCA the Formal Concept Analysis
as done by ToscanaJ and described in the 
1999 Springer-Verlag book 
by Bernhard Ganter and Rudolf Wille.

I'm of the impression that:
1) Any named concept of FCA must be defined 
as an object, in terms of attributes (only).  
2) The FCA algorithms will, based on the 
defined context,
find subconcepts having greater extent
and lesser intent. 

This is well-suited to a 
scientific/empirical situation where the
objects are data representing a 
discovered world.

But this is less than ideal for another
purpose: the establishment of an
agreed-upon set of terminology and
notions/concepts for a new field of study.

There, the more abstract concepts have a
"life of their own" and may not be
demolished or rejiggered
by some minor twiddle in the
context table's set of observations.

There, concepts should be able to be 
defined/asserted/concieved.  
They probably should be able to be
defined in terms of other concepts with
(presumed/hypothesized) lesser extent.
as well as in terms of attributes.

The slide show 
"Distinctive Features
as a Discursive andAnalytic Technique"
and the document
"Notes and a Partially-Worked Example"
explain more.

See also the motivational example at the
end of this text.

I know these ideas on using FCA for 
predefined subconcepts
are not fully baked
(maybe only half-baked) :-)!

Is this a new area of study or is it
one that's already well-addressed and I
simply don't know it?

Do you know of someone who'd like to
develop any of these notions in a 
collaborative way?

Any comments will be much appreciated!

   Regards,
     -Fred Chase



MOTIVATIONAL EXAMPLE:

In addition to the 
Security Information Management example
described elsewhere, the following
motivates the desire for a somewhat-modified
version of FCA.


I suggested to a colleague that we use
ToscanaJ to identify/discover/define all
the types of operating systems that 
differed with respect to computer security.

I tried to get him to define 
attributes and objects so that ToscanaJ could
discover the types of OSs.

But he couldn't be bothered:
he already, mostly, "knew" what the types were.

So we ended up with a kind of series of diagrams
on a page of paper, whose content is suggested by
the below.

We had a number of preconcieved notions about the 
middle of the concept lattice and wanted to use
that more nearly as a starting point, 
not as the end-result of detailing almost-innumerable
OSs, orthodox/acceptable and wierd.

Perhaps one would say that we wanted,
to a considerable extent, to define,
rather than to discover,
a world of OSs.

OS
 Win
 Unix
 Mainframe
Scope of Service
 Internal
  server
   enterprise
   dept
   local/lab
  desktop
 External
  server
   partners
   public
   identified customers
  desktop 
Priority of Service
 critical
 production
 lab
Security
 high
 elevated
 normal
Environment
 internal
  DMZ
  intranet
 external
  external
  extranet
ManagingOrganization
 WinIT_Desktop
 WinServer
 Network
 UnixSysadmin
 Mainframe